The location of a device is a useful information for many applications. The device might rely on its access network to provide the location information. This service may be provided by a location configuration server (LCS), wherein the device may request that the LCS provides a location reference in the form of a location URI (Uniform Resource Indicator) or a set of URIs, allowing the device to distribute its location information. The LCS may be accessed by a protocol, such as HELD (HTTP Enabled Location Discovery), which enables retrieval of the location information.
Schulzrinne, H., “Location-to-URL Mapping Architecture and Framework,” December 2006 describes a mapping server architecture with a mapping client (seeker or resolver) and a mapping server (resolver or other servers) for discovering server addresses. A query message carries location information and a service identifier encoded as a Uniform Resource Name (URN) (cf. Schulzrinne, H., “A Uniform Resource Name (URN) for Services,” August 2006) from a location-to-server translation (LoST) client to a LoST server. The LoST server uses its database to map input values to one or more Uniform Resource Identifiers (URI) and returns those URIs along with optional information, such as hints about the service boundary, in a response message to the LoST client. If the server cannot resolve the query itself, it may in turn query another server or return the address of another LoST server.
If a LoST URL contains a host name rather than an Internet Protocol (IP) address, clients need to use a naming authority pointer (e.g. U-NAPTR described for example in Daigle, L., “Domain-based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS),” October 2006).
Architecture for emergency calls make usage of the concepts of LoST servers and HELD servers. The LoST server is responsible for translation of location information into the URI of its closest PSAP (Public Safety Answering Point), while the HELD server is responsible for delivering the location of the user. The Location-to-LoST protocol specification describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services.
A common problem with location issues in IP emergency calls is related to find out which is the LoST or HELD server. This is because the LoST or HELD services have a boundary of operation. For example, a typical LoST server may be able to resolve location-to-PSAP belonging to the political country where the PSAPs belong. Or in big countries, a regional network operator may provide a LoST server which can resolve locations where the operator has coverage. Similar situations can apply to HELD servers as well.
This geographical limitation of LoST and HELD server leads to another problem: How can a device, such as an endpoint, find the URI or IP address of the LOST or HELD server that can provide the endpoint with location related information?
A current solution consist of using the dynamic host configuration protocol (DHCP) for retrieving the URI or IP address of a LoST server, as specified in Internet draft “A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure” (cf. http://tools.ietf.org/id/draft-ietf-ecrit-dhc-lost-discovery-02.txt). However, while this solution is technically feasible for fixed endpoints, which usually acquire an IP address with DHCP, the solution is of no use in wireless networks (e.g., in an IP Multimedia Subsystem (IMS)).
Mobile devices (e.g. mobile terminals or mobile nodes) do not typically use DHCP for acquiring an IP address when they use general packet radio services (GPRS) access networks with IP connectivity. Instead, they use the GPRS procedures (e.g., packet data protocol (PDP) context activation) to get an IP address.
On the other hand, since the mobile device might be moving, it can traverse the limit of operation of a PSAP. Therefore, the mobile device may need to discover its local LoST/HELD server at the time an emergency call is done, and not earlier.